<dependency>
<groupId>org.gatein.api</groupId>
<artifactId>gatein-api</artifactId>
<scope>provided</scope>
</dependency>
To provide support of the complex Portlet Lifecycle within CDI, we have created @PortletLifecycleScoped and @PortletRedisplayScoped for use with either JSF portlets or portlets extending GenericPortlet. These scopes are present within the GateIn API artifact, and are easily made available to your portlet project by adding the following Maven dependency:
<dependency>
<groupId>org.gatein.api</groupId>
<artifactId>gatein-api</artifactId>
<scope>provided</scope>
</dependency>
Note that there is no <version> necessary in the above <dependency> if you import GateIn BOM as described in Starting a Portlet Project.
A bean annotated with @PortletLifecycleScoped will be active for the full Portlet Lifecycle, from Action to Render. If you set a value on such a bean from within an ActionRequest or EventRequest, then retrieving that value from the bean within a RenderRequest will return the value that was previously set.
However, any further RenderRequest's that occur after the initial Portlet Lifecycle has completed, will not contain any values that may have been set as part of an ActionRequest or EventRequest. For this reason, the @PortletLifecycleScoped is best suited to situations where it does not matter if the value is only present for the first render, such as wanting to display a message on the portlet to the user as a result of some action that was performed.
A ResourceRequest is considered separate from the regular Portlet Lifecycle, so any changes to a CDI bean within a ResourceRequest will not be reflected in the instance of the bean used during an ActionRequest, EventRequest or RenderRequest, just as any changes to bean state within these requests will not be reflected in the instance that a ResourceRequest sees.
A bean annotated with @PortletRedisplayScoped will be active until a subsequent Portlet Lifecycle triggered by an ActionRequest or EventRequest is initiated. This takes @PortletLifecycleScoped a step further by supporting the use case of needing to display the same data each time the portlet is refreshed without any new actions or events being triggered. It does not matter how many RenderRequest}}s are made, the data will be retained for redisplay until a new {{ActionRequest or EventRequest is triggered, causing the beans to be re-initialized to their default state.
As @PortletRedisplayScoped is passivation capable, it needs to implement Serializable.
A ResourceRequest will have any @PortletRedisplayScoped annotated bean initialized to its default state, but any bean that has its methods called will overwrite any existing instances of that bean upon completion of the ResourceRequest. This enables a subsequent RenderRequest to reflect the values that were set as part of a ResourceRequest, the typical use case for this scenario being Ajax calls from the browser.
As @PortletRedisplayScoped beans will have a CDI client proxy injected into the beans instead of the actual instance, it's important to remember that calling a get method on a bean during a ResourceRequest will result in its initialized state overwriting whatever is present in the instance that will be used for a RenderRequest. Ensuring that you only call methods on beans that you want reflected in the next RenderRequest during a ResourceRequest will ensure that you don't see unexpected data changes on a portlet refresh.
There is Portlet Using CDI Scopes example project available in our Quickstarts Collection. It demonstrates the usage of CDI Scopes @PortletLifecycleScoped and @PortletRedisplayScoped.